Internet Engineering Task Force (IETF) G. Salgueiro 


Request for Comments: 6869 J. Clarke 
Category: Standards Track P. Saint-Andre 
ISSN: 2070-1721 Cisco Systems 


February 2013 


vCard KIND:device 
Abstract 
This document defines a value of "device" for the vCard KIND property 
so that the vCard format can be used to represent computing devices 
such as appliances, computers, or network elements (e.g., a server, 
router, switch, printer, sensor, or phone). 
Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 
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received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
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1. Introduction 
Version 4 of the vCard specification [RFC6350] defines a new "KIND" 
property to specify the type of entity that a vCard represents. 
During its work on the base vCard4 specification, the VCARDDAV 
Working Group defined values of "individual", "org", "group", and 
"location" for the KIND property. 
During working group discussion of the document that became 
[RFC6473], consideration was given to defining a more general value 
of "thing", but it was decided to split "thing" into software 
applications and hardware devices and to define only the 
"application" value at that time. Since then, use cases for device 
vCards have emerged. These use cases involve using vCards as a 
primer for inventory and asset tracking data specific to network 
elements. Therefore, this document complements [RFC6473] by defining 
a value of "device" for the KIND property to represent computing 
devices such as appliances, computers, or network elements. In this 


context, the concept of a device is constrained to computing devices 
and thus is distinct from purely mechanical devices such as 
elevators, electric generators, etc., that cannot communicate in any 
way over a network. This does not preclude, however, network- 
attached sensors that are connected to such mechanical devices. 


2. Scope 


When the KIND property has a value of "device", the vCard represents 
a computing device such as an appliance, a computer, or a network 
element (e.g., a server, router, switch, printer, sensor, or phone). 
More formally, a "device" is functionally equivalent to the "device" 
object class used in the Lightweight Directory Access Protocol 
[RFC4519] as derived from the Open Systems Interconnection model 
[X.521] [X.200]. However, whereas [X.521] specifies that devices are 
"physical" elements, a device in this context can also be virtual 
such as a virtual machine running within another physical element. 
As one example of the "device" KIND, vCards can be embedded into 
devices at manufacturing time so that basic information such as 
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serial number, support email, and documentation URL can be retrieved 


upon initial deployment. This vCard can be modified after the device 
is deployed to contain user-specified data about the device’s 
characteristics. The vCard data can therefore be used for both asset 


tracking and operational purposes. 


A device might have a number of embedded vCards for varying purposes. 
The process for discovering and accessing these vCards is 
purposefully left unspecified in this document, as this process could 
rely on any mechanism that makes sense for the device in question. 
For example, a device could have one or more of the following vCard 
instances: 


o The device itself. For example, the FN ("full name") property 
might represent the hostname of a computing device; the URL 
property might represent a website that contains details on where 
to find documentation or get further information about the device; 
the KEY property might represent a digital certificate that was 
provisioned into the device at the time of manufacture 
[IEEE.802.1AR], or a public key certificate previously provisioned 
into the device; and the ADR, GEO, and TZ properties might 
represent the physical address, geographical location, and time 
zone where the device is deployed. 


o An organization or person that produces or manufactures the 
device. 


o A person or role that maintains or administers the device. 


o Application-level vCards as described in [RFC6473] for each 
application installed on the device. 


When a device has vCards other than its KIND:device vCard, those 
vCards can be linked together with RELATED (see the definition of the 
RELATED organizational property in Section 6.6.6 of [RFC6350]). In 
multi-vCard instances, the KIND:device vCard would use the RELATED 
property to express the relationship with the ancillary vCard(s). 
Those supplementary vCards need not use RELATED to point back to the 
KIND:device vCard. In this manner, the vCard for the device itself 
can be easily distinguished from vCards referring to the vendor 
organization, device administrator, and installed applications. 
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The following base properties make sense for vCards that represent 
devices (this list is not exhaustive, and other properties might be 
applicable as well): 


ADR 
EMATL 
FN 

GEO 
IMPP 
KEY 
KIND 
LANG 
LOGO 
NOTE 
ORG 
PHOTO 
RELATED 
REV 
SOURCE 
TEL 

TZ 

UID 
URL 


+ + + + ok oko ooo 0o FF FF FF FF FF RS RS Ro F X 


Although it might be desirable to define a more fine-grained taxonomy 
of devices (e.g., a KIND of "device" with a subtype of "router" or 
"computer"), such a taxonomy is out of scope for this document. 


3. Example 


The following is an example of a router device that contains both 
manufacturing details as well as post-deployment attributes and uses 


the XML representation of vCard (xCard) described in [RFC6351]. This 
vCard points to another, related vCard that contains the details of 
an administrative contact for the device. This vCard also leverages 


the extensibility of the xCard format to reference additional 
namespaces in order to provide richer details about the given device 
(e.g., the serial number and software version are specified as xCard 
extensions). 
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<vcard xmins="urn:ietf:params:xml:ns:vcard-4.0"> 
<kind><text>device</text></kind> 
<fn> 
<parameters> 
<type><text>x-model-name</text></type> 
</parameters> 
<text>RTR1001</text> 
</fn> 
«fn»«text»core-rtr-l.example.net«/text»«/fn» 
«url»«uri»http://www.example.com/support/index.html«/uri»«/url» 
<email><text>support@example.com</text></email> 
<email> 
<parameters> 
<type><text>x-local-support</text></type> 
</parameters> 
<text>network-support @example.net</text> 
</email> 
«impp»«uri»xmpp:core-rtr-1G8example.net«/uri»«/impp» 
«related» 
«parameters» 
<type><text>contact</text></type> 
</parameters> 
«uri»urn:uuid:5CEF1870-0326-11E2-A21F-0800200C9A66«/uri» 
«/related» 
<logo><uri>http://www.example.com/images/logo.png</uri></logo> 
<geo><uri>geo:35.82,-78.64</uri></geo> 
<tz><text>America/New York</text></tz> 
«rev»«timestamp»20120104T213000Z«/timestamp»«/rev» 
<uid><uri>urn:uuid: 00CCFB88-155F-40F6-B9D9-B04D134860C0</uri></uid> 
<serial-number xmlns-'http://example.org/profiles/serial-number'» 
FTX1234ABCD 
</serial-number> 
<note> 
<parameters> 
<type><text>x-contract-number</text></type> 
</parameters> 
<text>1234567</text> 
</note> 
«mac xmlns-'http://example.org/profiles/mac'» 
00-00-5E-00-00-01 
«/mac» 
«sw-version xmlns-'http://example.org/profiles/sw-version'» 
2.1.5 
</sw-version> 
</vcard> 
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4. IANA Considerations 


IANA has added the following entry to the "vCard Property Values" 
table of the "vCard Elements" registry 
(http://www. iana.org/assignments/vcard-elements): 


4---------- 4-------- 4--------------------- * 
| Property | Value | Reference | 
4---------- 4-------- 4--------------------- + 
| KIND | device | RFC 6869, Section 3 | 
4---------- 4-------- 4--------------------- * 


Table 1: IANA Registration of KIND:device vCard Property Value 


In conformance with Section 10.2.6 of [RFC6350], the registration 
template is as follows: 


Value: device 


Purpose: The entity represented by the vCard is a computing device 
such as an appliance, computer, or network element. 


Conformance: This value can be used with the "KIND" property. 
Example: See Section 3 of RFC 6869. 
5. Security Considerations 


Registration of this vCard KIND to represent devices does not in 
itself introduce security considerations beyond those specified for 
vCards in general as described in [RFC6350]. Nevertheless, risks can 
arise for vulnerable Internet-connected devices as a result of the 
publication of the identification details provided by device vCards. 
Well-known publicly accessible device vCard repositories, while not 
defined in this document, can increase the probability of an 
exploitation of an existing vulnerability, especially for devices 
with no good way to update their software or firmware. It is the 
responsibility of the device administrator to adhere to best current 
security practices and employ proper strategies for software upgrades 
and security patches in order to mitigate vulnerability to attack. 
Specifications defining device-specific vCard extensions or profiles 
that might be included in such vCards also need to consider this 
potential increased risk. 
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